Note: CodeRabbit is enabled on this repository as a convenience for maintainers
and contributors. Use your best judgment when considering its review comments and
suggestions — a suggested change may be inadequate, unnecessary, or safe to ignore.
Contributors are not expected to address every comment. Human reviews are what
ultimately matter for merging.

Overview

This PR replaces a broken sequence-detection trait used by the arguments framework. The previous element-type-based logic misclassified many types (e.g., treating tuple/complex-like types and some wrappers as sequences, and preventing iterators/pointers from being passed as single values). The new approach narrows what is considered a sequence to arrays, types meeting ranges::range, or types that provide random-access traversal. Tests were added/adjusted to lock in the intended behavior and avoid regressions.

Changes

Implementation (libcudacxx/include/cuda/__argument/argument.h)

• Redesigned __is_sequence_v:
  • New definition: is_array_v<remove_cvref_t<_Tp>> || ranges::range<_Tp> || __has_random_access_traversal<_Tp>.
  • This replaces the old element-type-comparison logic that caused misclassification.
• Removed helper variable templates: __is_single_value_v and __is_iterable_v (old element-type helpers).
• Primary traits behavior changed:
  • The primary __traits_impl<_Tp>::is_single_value no longer depends on the removed helper; the primary template is effectively made single-value-friendly (tests show raw pointers/iterators are treated as single values in trait queries).
• Validation logic:
  • __immediate::__validate_value remains focused on single-value detection for arithmetic element types.
  • __immediate_sequence::__validate_value:
    • If __has_random_access_traversal<_Arg>, validation uses the random-access path (dereferencing the iterator/pointer).
    • Else, when __is_sequence_v<_Arg> and the element type is arithmetic, the code iterates the range to validate elements.
  • __constant_sequence static_assert message updated to require a “range or an array”.

Tests

• libcudacxx/test/libcudacxx/cuda/argument/argument_traits.pass.cpp
  • Expanded negative coverage: static_assert that cuda::std::complex, pair, tuple, optional, expected are not sequences.
  • Confirmed plain types and wrapper-like types (range_like, element_type_like, value_type_like) are not sequences.
  • Confirmed pointers and counting iterators are sequences only when they provide random-access traversal; bidirectional iterators are not sequences.
  • Kept C arrays, spans, and std::array classified as sequences.
  • Updated argument_traits expectations: e.g., cuda::__argument::__traits<int*>::is_single_value is asserted true (reflecting the traits primary-template change).
• libcudacxx/test/libcudacxx/cuda/argument/dynamic_argument.pass.cpp and static_argument.pass.cpp
  • Replaced previous __is_single_value_v assertions with assertions using !__is_sequence_v for unwrapped/value_type checks where appropriate.
• libcudacxx/test/libcudacxx/cuda/argument/usage_example.pass.cpp
  • One plain-span test block is currently disabled (#if 0) with a FIXME comment.

Rationale & Impact

• Aligns sequence detection with standard range terminology while preserving practical handling of random-access iterators/pointers where CUB historically allowed them.
• Prevents misclassifying tuple-like or scalar-like types (e.g., std::complex) as sequences.
• Tests added/updated to prevent regressions and to codify the intended semantics.
• Note: runtime validation for random-access iterator/pointer sequences still uses dereference-based checks (with a FIXME comment noting that size may be unknown); reviewers may wish to consider whether additional iterator-size/validation strategies or clearer documentation are desirable.

Notes for reviewers

• The change intentionally narrows __is_sequence_v but also alters the primary traits behavior so that some pointer/iterator cases remain treated as single values in trait queries. Verify this trade-off matches CUB compatibility goals.
• The PR discussion suggested alternatives (broader acceptance of iterators/pointers, eliminating extra validation, or different validation strategies). This change adopts a middle path: standard-like detection of ranges plus explicit support for random-access traversal where needed.

Walkthrough

suggestion: Reclassifies sequence detection: a sequence is now an array (after cv/ref removal), a ranges::range, or has random-access traversal; removes __is_single_value_v/__is_iterable_v; updates immediate-sequence validation, trait primary template, and tests to use __is_sequence_v (negated for single-value).

Changes

Argument type classification by ranges::range

• Possibly related PRs:

  • NVIDIA/cccl#8875: Related changes to argument.h sequence/single-value trait logic.

• Suggested labels: libcu++

• Suggested reviewers:

  • Jacobfaib

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

I have added some more tests to make sure this does not regresses again. I believe we can agree that complex<float> is not a range

I am not tied to the name of this trait, but at the end of the day when user passes something that has bounds we need to understand if its one value or multiple values. We have the _sequence wrappers for that, but I wanted to provide some validation in it, this trait was supposed to answer if the thing in the wrapper looks like multiple values and what is the element type, so we can assert the values are within bounds.

I highly doubt we can convince others CUB should stop accepting iterators and pointers, so I believe we need a broader definition than just range, but maybe we can also remove the extra validation, which would remove the need for this trait. But it is likely in that case a similar trait would need to live in CUB anyway, so I am not sure if it isn't just pushing the problem to a different place

I highly doubt we can convince others CUB should stop accepting iterators and pointers

We should be able to still allow pointers and iterators if that is intended, but then the check should probably be __has_random_access_traversal or similar

Also we need to then differentiate iteration over a range and iteration over an iterator. Currently the check in __validate_value only considered ranges and not iterators

The issue I have here is that a pointer / iterator does not communicate the size of the range. In a perfect world we would just pass transform_view rather than transform_iterator

Not a hill to die on definitely but I at least want to make sure that we do not consider tuple or complex as sequences

😬 CI Workflow Results

🟥 Finished in 1h 04m: Pass: 99%/115 | Total: 21h 05m | Max: 33m 37s | Hits: 98%/343670

See results here.